LabVIEW Idea Exchange

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

We know that LabVIEW has some magic that it uses for automatic error handling.  What if LabVIEW could use such sorcery to enrich the error string flowing on the wire, with information about the originating source of the error -- specifically the VI Reference and GObject UID of the node where the error was introduced.  Then a "fancy error dialog of the future" (TM) could utilize those UIDs to navigate directly to the node and highlight it (a visual effect to show which node it is). This behavior could be added to the Simple Error Handler and General Error Handler VIs, and maybe ever there could be a "LabVIEW Gems" vi.lib utility that can extract the VI Reference and GObject UID for use in other, 3rd party tools.

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

 - Data nodes of timed structures (timed loop, timed sequence).

 - I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

Currently VI's show up in whatever taskbar's monitor they first showed up in and don't follow if they are moved to a different monitor.

This makes my workflow very difficult as I can end up with 18 VI icons (1 each block diagram and front panel) on Monitor 2 and 0 VI icons on  Monitor 1.  This despite the fact that might have moved have of the VI representations to Monitor 1.  The only way to distribute them among the taskbars is to restart windows explorer.  This is annoying to have to do even though I have a script to do it (thanks to the hero that posted that process!).

Relatedly, I don't always want all VIs to pop up when I want one to show up.  I should be able to bring a block diagram up without having every other VI front panel and block diagram also pop up.  Then I have to go and minimize each window individually so I can look at a document or spreadsheet at the same time.

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

 - Queue

 - Notifier

 - User event

 - DVR

 - Datalog file reference

 - Strictly-typed control refnum

 - Strictly-typed VI refnum

 - Shared variable

 - Network stream (reader/writer)

 - RT FIFO

 - FPGA IO / register / memory / FIFO / handshake

 - ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

I want to be able to programmatically change the color of the LEDs on push buttons.

The colors[4] property will change the color of the housing, but not the LED itself.

This push button is one of the controls that is both a control and an indicator rolled into one.

In my particular case, I want to represent a third state. I have a valve that can be open, closed, or in transit.

There are two actuation states of open and close, but three indicator states.

I think making it a property I can control is a powerful solution. Not only will it solve my use case, but I can have all different colors of Booleans without needing to use Customize Control and the Control Editor to modify the colors.

Extra credit request: Can we make just the LED blink?  Right now, the blinking property blinks the entire control, but wouldn't it be cool if just the LED blinked? This is what those same two controls look like when blinking:

Maybe it's a new property just for LEDs that's separate from "Blinking". I'd be okay with that if you want to preserve current behavior.

Here are some related Idea Exchange posts related to a tri-state Boolean. They're not quite what I want, but I thought I'd link to them for reference:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Tri-State-Boolean/idi-p/1139952

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Special-LED-control-with-three-states-Default-ON-OFF/idi-p/991307